2.1.1 Zur allgemeinen Struktur volltexterfasster Dokumente

2.1.2 Postalische Dokumente

In der digitalen Briefedition werden die postalischen Dokumente der ausgewählten Korrespondenzen – also Briefe und Gegenbriefe – wiedergegeben. Es handelt sich dabei um verschiedene Dokumenttypen wie Briefe (zum Teil mit Umschlag), Post- und Briefkarten sowie Telegramme, die unterschiedliche Anforderungen an das Datenmodell stellen, weshalb diese im Folgenden getrennt behandelt werden.

2.1.3 Schriftstücke

Weitere Dokumente, die im Zusammenhang mit der Korrespondenz überliefert sind, das sind in der Regel Beilagen zu Briefen wie Aufstellungen, Listen, Rechnungen, Zeitschriftenartikel etc., werden einzeln erfasst. Sind die Dokumente eindeutig als Beilage eines Briefes nachzuweisen, so werden diese mit dem entsprechenden Brief verlinkt:²

2.1.4 Übersetzungen

Übersetzungen von postalischen Dokumenten werden angefertigt, wenn die Dokumente in einer anderen Sprache als deutsch oder englisch vorliegen. Bisher betrifft dies vor allem Dokumente in spanischer oder französischer Sprache. Die Übersetzungen werden mit demselben Schema erfasst wie das Originaldokuemnt, sie erhalten aber nur minimale Metadaten, in denen vor allem auf das Original-Dokument verwiesen wird.

In den Übersetzungen werden lediglich Personen, Institutionen und Orte ausgezeichnet. Anmerkungen zur Textkonstitution und Zeilenkommentare bleiben dem Original vorbehalten.

2.2.1 Personen

Personen-Datensätze enthalten innerhalb des Root-Elements person die grundlegenden Angaben zur jeweiligen Person: Familienname surname, Vorname forename und ggf. Namenszusätze wie z. B. ‘von’ nameLink sowie roleName. Dabei gibt es eine reguläre Ansetzungform <persName type="reg">, es können aber auch Alternativnamen erfasst werden <persName type="alt">, näher spezifiziert durch das Attribut subtype, welches beispielsweise Angaben zu Taufnamen oder Namensänderungen durch Heirat usw. beschreibt: <persName type="alt" subtype="married">.

Ist eine Person innerhalb einer Organisation tätig oder tätig gewesen, so wird diese Beziehung mit affiliation angegeben. <affiliation key="{OrgId}">. Handelt es sich um eine zeitlich begrenzte Tätigkeit, deren Dauer für die Edition relevant ist, so kann dieser Zeitraum mit den Attributen from und to angegeben werden.

2.2.2 Werke

Dieser Datentyp ist äußerst komplex, da musikalische und literarische Werke auf unterschiedliche Weisen erfasst werden müssen. Für die musikalischen Werke finden die Kodierungsempfehlungen der Music Encoding Initiative (MEI) Anwendung; für literarische Werke die der Text Encoding Initiative (TEI). Aus diesem Grund werden die beiden Untergruppen dieses Dokumententyps im Folgenden separat besprochen. Beide Werkgruppen sind noch im Aufbau und werden im Laufe des Projektes weiter differenziert.

2.2.3 Orte

Referenzdatensätze zu Orten werden einzeln angelegt, dabei ist es nicht von Belang, ob es sich um ein Land, eine Stadt oder z. B. ein Gebirge handelt, jeder identifizierbare Ort wird durch einen eigenen Datensatz repräsentiert. Als Normdatenbank wird primär GeoNames verwendet. GeoNames stellt eine äußerst umfangreiche Datensammlung bereit, die neben Städten auch Örtlichkeiten, wie Schlösser, öffentliche Gebäude u.a. enthält; zudem sind die Datensätze von GeoNames hierarchisch organisiert (bspw. Kontinent, Land, Region, Stadt).

Das Datenmodell für Orte ist von einfacher Struktur.

Für den Fall, dass ein Ort nicht in der GeoNames-Datenbank verfügbar ist, können ggf. die Koordinaten ermittelt und im Datensatz nach folgendem Schema hinterlegt.

2.2.4 Organisationen/Institutionen

Bei Referenzsdatensätzen zu Organisationen werden neben den Normdaten derzeit nur Name und Ort erfasst. Der ‘Typ’ der Orgnaisation, z. B. Verlag, Theater, Rundfunkanstalt, wird in einem state-Element erfasst. Literaturangaben bzw. links sind in listBibl möglich.⁴

Unterorganisationen wie Abteilungen, Projektgruppen und organisationshierarchische Untersektionen werden als eigene Organisation erfasst. Dies gilt auch für Firmen bei Namenswechsel. Die Zuweisung zum Übergeordneten Datensatz erfolgt mittels <relation>:

2.2.5 Rollen und Charaktere

Erwähnte Rollen aus dramatischen Werken oder Charakteren in Prosawerken oder Lyrik werden im Brieftext ausgezeichnet – <name type="role"> bzw. <name type="character"> – ein Register für diese Namen ist jedoch noch in Diskussion.

2.2.6 Literatur

2.2.7 Erfassung von Ereignissen

Das Datenmodell zur Erfassung von Ereignissen befindet sich im Aufbau.

3.3.1 Abschnitte <div>

In der Regel enthält ein Brief nur einen div. Ausnahmen sind Briefe, die von verschiedenen Personen geschrieben sind, und Briefe, die eindeutig an verschiedenen Tagen (writingSessions) geschrieben sind. Beilagen wie Dokumente oder Rezensionen aber auch Umschläge werden getrennt erfasst, aber in dem Brief verlinkt.

3.3.2 Absätze <p>

Die grundsätzliche Gestaltung der Absätze wird in den Angaben zum Layout layoutDesc beschrieben: Zeilenabstand, Einzüge, Abstände, wobei die Angaben bei Typoskripten exakter sein können als bei handschriftlich überlieferten Dokumenten. Weicht ein Absatz davon ab, wird dies als Attribut in p vermerkt. Für den Einzug wird hierbei das space verwendet. Die Breite des Einzugs wird wie auch bei anderen Abständen in der Zahl der Buchstaben oder in Abständen von ca. 2cm angegeben. Wird in der layoutDesc kein Einzug standardmäßig für die Absätze angegeben, beginnen Absätze ohne weiteres Attribut am linken Rand.

3.5.1 Trennstriche

Ein "normaler" Zeilenumbruch wird durch lb dargestellt. Ein Zeilenumbruch, der innerhalb eines Wortes vorlommt und durch einen Trennstrich orthographisch realisiert ist, wird mit lb break="no" codiert. Ein vergessener Trennstrich wird mit <lb break="no" rend="noHyphen"> codiert!

3.5.2 Abkürzungen <abbr>

Abkürzungen, die unverständlich bleiben und sich nicht durch bloße Ergänzung auflösen lassen, werden in ihrer originalen Form und zusätzlich als wahlweise aufzurufende Vollform wiedergegeben:

3.5.3 Schreibversehen

Schreibversehen (wie z. B. versehentliche Wortwiederholungen) werden in der Regel so übernommen und durch das Element sic markiert, um eine spätere irrtümliche Korrektur durch einen Editor zu verhindern. Dort, wo solche Schreibversehen zu Leseschwierigkeiten führen, kann in einem choice-Element neben der originalen Schreibung (sic oder <orig>) eine vom Editor angebotene Korrektur angeboten werden (mit <corr resp="XY">.

3.5.4 Fremdsprachliche Textteile

Die Korrespondenz von Henze und seinen Partnern verwendet sehr unterschiedliche Sprachen und fügt immer wieder Wörter, Satzteile oder ganze Passagen in anderen Sprachen ein. Die Grundsprache eines Briefes wird in den Metadaten angegeben, hiervon abweichende Sprachen werden mit foreign gekennzeichnet. Wenn es sich bei den verwendeten Sprachen um andere als deutsch und englisch handelt, so wird eine Übersetzung angeboten.

Das den fremdsprachlichen Anteil kennzeichnende Element foreign erhält hierzu eine xml:id nach dem Muster foreign.\d+. Die einzelnen Vorkommen werden dokumentweise durchgezählt. Im notesStmt werden die Übersetzungen hinterlegt und mit dem correspondierenden Element im Text assoziiert.

3.5.5 Anführungszeichen

Die Verwendung von Anführungszeichen zur Hervorhebung einer Phrase ist von einem Zitat zu unterscheiden. Während das Element q lediglich die Anführungszeichen repräsentiert, markiert das Element quote ein Zitat. Im Rahmen der Edition werden Anführungzeichen durch die Verwendung dieser beiden Elemente ersetzt, sodass im codierten Text keine Anführungszeichen enthalten sind. Damit aus inhaltlicher Sicht kein Defizit entsteht, werden Abweichungen "von der Norm" codiert.

Diese anzulegende Norm wird in mehreren Schritten definiert:

• Sprache des Dokumentes
• Schreibeigenheiten des Autors
• Eigenheiten des Dokumentes

Finden sich keine weiteren Angaben, so ist die Sprache des Dokumentes maßgebend. Das heißt, dass q oder quote doppelte Anführungszeichen in der definierten Sprache des Dokumentes darstellen. Sind Schreibeigenheiten des Autors bekannt, die durch die Häufigkeit ihrer Verwendung eine Art Norm bilden, so haben diese Vorrang vor der Sprache des Dokumentes. Weist ein Dokument jedoch Eigenheiten auf, die innerhalb des Dokumentes als Standard anzusehen sind (bspw. die konsequente Verwendung von Sternchen als Anführungszeichen) haben diese die oberste Priorität.

Codiert werden immer nur Abweichungen von der jeweils geltenden Norm!

Die unterstützen Zeichen sind:

• „[...]“ und ,[...]‘ (deutsch)
• “[...]” und ‘[...]’ (englisch)
• «[...]» und ‹[...]› (französisch)

Werden also keine näheren Angaben gemacht, stehen die Elemente q und quote stellvertretend für doppelte Anführungszeichen in der definierten Sprache des Dokumentes.

Handelt es sich um einfache Anführungszeichen, so ist das entsprechend zu codieren:

Wenn Anführungszeichen einer anderen Sprache verwendet werden, dient das Attribut xml:lang dazu diese Sprache zu definieren.

Wenn die Zeichen ungleichmäßig voneinander abweichen, kann dies über eigens dafür definierte Attribute (rendLeft, rendRight) angegeben werden.

Auch der Fall, dass eines der beiden Zeichen oder beide fehlen kann auf diese Art codiert werden. Für ein Fehlen wird der Wert none verwendet. Durch den Umstand, dass bei der Verwendung der Elemente q und quote ein Anfangs- und Endpunkt zwangsläufig definiert werden muss, kommt diese Form der Codierung einer editorischen Ergänzung gleich.

Zum Hintergrund dieses Modells: Ziel der Edition ist es den Inhalt im Code adäquat abzubilden. Gleichzeitig ist auch die Vermittlung der Forschungsdaten ein wichtiger Aspekt. Ersteres ließe sich auch dadurch realisieren, dass die Anführungszeichen als Textzeichen in die Dateien eingegeben werden. Ein solches Vorgehen verwehrt jedoch die Möglichkeit eine Lesefassung anzubieten, in der z.B. sämtliche Zeichen normalisiert sein könnten. Um also eine Steuerung dieser Zeichen in der späteren Anzeige zu ermöglichen, ist es notwendig diese ansteuerbar zu machen. Gleichzeitig soll der Inhalt aber nicht dadurch defizitär werden, dass Rückschlüsse auf das Original (Diplomatik) nicht mehr möglich sind. Aus diesen Gründen werden die Anführungszeichen entsprechend auscodiert. Das Modell der Norm-Hierarchie bringt zwar eine weitere Ebene hinein, durch welche die Komplexität weiter steigt, jedoch müssen dadurch nur wenige Stellen explizit codiert werden, nämlich die Abweichungen. In der Konstitution komplex, erleichtert dieses Modell die Erarbeitung der Edition.

3.5.6 Musiknotation

Sind in den Dokumente Notenbeispiele erhalten, so werden sie innerhalb des Elements notatedMusic als MEI-Datei eingefügt.

3.5.7 Sonstige Symbole und Grafiken

Eingefügte Zeichnungen und Graphiken werden mit figure codiert und in der figDesc beschrieben.

3.6.1 Autoreigene Tilgungen

3.6.2 Autoreigene Ergänzungen

Einfügungen, die der Autor (Schreiber) nachträglich oder im Schreibvorgang vorgenommen hat, werden (sofern es sich nicht um Korrekturen durch Eingriffe in die ursprüngliche Substanz) handelt, mit dem Element add (addition) vermerkt. Dabei sollte der Ort der Einfügung mit Hilfe des Attributs place bezeichnet werden. Als Attributwerte kommen dabei in Frage: „inline“, „margin“, „above“ (the line), „below“ (the line) oder „mixed“. Stammen solche Einfügungen von anderer Hand, kann dies im Attribut hand ausgewiesen werden. Hinweis: Einfügungen und Zusätze des Herausgebers werden nie mit add, sondern mit corr oder subst vorgenommen!

3.6.3 Autoreigene Korrekturen

Sind z. B. in Typoskripten notwendige Korrekturen, oft nachträglich, nur mit Korrekturzeichen angegeben (z. B. zu tauschende Buchstaben mit dem entsprechenden Korrekturzeichen) so wird dies in einer Anmerkung beschrieben.

3.6.4 Unleserliche Stellen

3.6.5 Unsichere Lesung

Alle nur aus Leseschwierigkeiten der Handschrift resultierenden Unklarheiten werden in das Element unclear eingeschlossen. Sofern mehrere Deutungsmöglichkeiten vorhanden sind, werden diese innerhalb des Elements choice zur Auswahl gestellt. In diesem Falle sollte bei den Einzellesungen das Element unclear durch ein Attribut cert (certainty) ergänzt werden. Als Werte kommen dafür ‘high’, ‘medium’, ‘low’ oder ‘unknown’ in Frage. Durch das hinzugefügte Attribut resp ist dabei der für diese Einschätzung verantwortliche Editor erkennbar.

3.7.1 Ergänzungen der Herausgebenden

Gelegentlich kann es vorkommen, dass der Autor zum besseren Textverständnis einzelne fehlende Zeichen oder auch Zeichenfolgen bzw. Worte ergänzen muss/möchte (wenn dies die Folge von Textverlusten ist, vgl. allerdings die Rubrik ‘Unleserliches 1’). Diese Ergänzungen werden mit dem Attribut @resp innerhalb von supplied vorgenommen (Bsp.: heute kam Friedr<supplied resp="editor">i</supplied>ch). Alle auf diese Weise vorgenommenen Ergänzungen erscheinen z.Zt. im Text in eckigen Klammern.

3.7.2 Korrekturen der Herausgebenden

(sofern für das Verständnis zwingend): Es kommt vor, dass ganz offensichtlich Falsches zu Missverständnissen führt und besser korrigiert werden sollte. Zur Kennzeichnung der originalen Schreibung wird nun ein sic-Element verwendet (das auch eingetragen werden kann, um die Tatsache eigenartiger Schreibungen hervorzuheben, damit in späteren Korrekturgängen an dieser Stelle nicht fälschlich ein Verschreiber des Übertragenden angenommen wird). Die Korrektur selbst kann dann durch corr angegeben werden und der Urheber sollte sich als Verantwortlicher (@resp="IC") eintragen. Das Ganze wird in ein choice-Element eingeschlossen, um eine wahlweise Darstellung zu ermöglichen.

3.7.3 Kommentare der Herausgebenden

3.11.1 Personen

In der Auszeichnung von Personen ist zu unterscheiden, ob der Name einer Person genannt wird oder eine Be- bzw. Umschreibung. Wird der Name genannt, ist persName zu verwenden, gibt es nur eine (indirekte) Beschreibung einer Person wie ‘sein Bruder’, ‘die Ärtze’ oder ‘die Musiker’, so ist rs mit dem @person oder @persons zu verwenden. Auszeichnungen von Personen sollten immer zur eindeutigen Bestimmung mit Hilfe eines @key verwendet werden. Werden mehrere Personen in einem Wort angesprochen, z. B. Ehepaar Müller, sind die keys beider Personen in dem Element als Attribut zu ergänzen. Achtung: da der Personennamen dann nicht eindeutig ist wird in diesem Fall, trotz Namensnennung, rs verwendet. Nur in rs können mehrere keys gesetzt werden.

Bei biblischen oder mythologischen Namen wird name verwendet und jeweils präzisiert mit @myth oder @biblical. Ebenso werden Namen von dramatis personae (Rollen) aus Schauspielen oder Musiktheaterstücken, z. B. Elisabeth Zimmer, Dr. Wilhelm Reischmann (aus: ‘Elegie für junge Liebende’) mit @actingRole oder Figuren aus Prosatexten wie Wilhelm Meister mit @character spezifiziert

3.11.2 weitere Namen

GEopolitische Namen werden direkt mit den zugehörigen Elementen district, settlement, region, country, bloc ausgezeichnet und mit einem key versehen. In dem zugehörigen Datensatz wird dann über ‘geoNames’ die Angabe präzisiert. Ortsangaben, die keine politische sondern geographische Einheiten bezeichnen, werden mit geogName und @type codiert: z. B. forest, island, lake, mountain, river.

Es bleiben jedoch einige Namen, die mit name und einem Attribut bestimmt werden müssen: vor allem Werke @work oder @works und Aufführungsorte @venue. Gerade bei Theatern ist dabei sorgfältig zu unterscheiden, ob in dem Brief z. B. ‘Mailander Scala’ als Aufführungsort oder als Organisation angesprochen ist.

3.11.3 indirekte Angaben

Für alle indirekten Erwähnungen, nicht nur für Namen (s.o.), ist rs zu verwenden und ist das Element mit Attributen zu präzisieren. Dies wird auch verwendet, um auf angesprochene postalische Dokumente zu verweisen wie z. B.: "dein letzter Brief". Anschließend folgt der Key des angesprochenen Gegenstandes. [kann man hier automatisch die Liste der erlaubten types einfügen?]

3.11.4 Datumsangaben

Alle Datumsangaben werden, damit sie prozessierbar werden, mit date ausgezeichnet und mit Hilfe eines Attributs in ein normiertes Datum umgesetzt, z. B. wird 3. Januar 1956 als date ausgezeichnet mit @when="1956-01-03". Zeiträume werden in dem Element mit @from @to wiedergegeben, also ‘zwischen dem 5. und 8. März 1958 werde ich bei Euch sein’ wird zu @from="1958-03-05" @to="1958-03-08". Ist nur ein ungefährer Zeitraum wie Ende März angegeben, so wird dies mit @notBefore="1958-03-20" @notAfter="1958-03-30" ausgezeichnet. Die Jahreszahl muss in jedem Fall ergänzt werden, auch wenn sie wie im letzten Beispiel im Text nicht genannt ist.

3.11.5 Datierungen

Die Datumsangaben in der in einem Brief üblichen dateline wird codiert wie alle anderen Daten. Wird ein Datum oder ein Teil davon erschlossen, so wird dieses Datum mit supplied als vom Herausgeber ergänzt markiert.

In den Metadaten unter correspAction wird das erschlossene Datum ‘normal’ eingetragen, allerdings erhält das Element date dann ein Attribut @type="editor". ebenfalls hervorgehoben mit einem @type="postal" sind Datumsangaben, die nicht auf Angaben des Autors, sondern auf postalischen Angaben wie Stempel oder Postvermerke zurückgehen. Bei allen date-Angaben ohne Attribut ist von dem Attribut @type="source" auszugehen. Da dies der Normalfall ist, wird er nicht ausdrücklich codiert.

3.11.6

#102: prüfen, ob wir alles mit name abdecken.